home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0059.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  7.2 KB  |  161 lines
  1. Based on feedback to date, a few words have been changed.  Here are the 
  2. diffs, followed by the latest version.
  3.  
  4. -teg
  5.  
  6. ===========================================================================
  7. OLD <
  8. ---
  9. NEW >
  10.  
  11. Re: Definitions (2nd paragraph):
  12. < manipulating email message data on a remote mail store (repository).  Mail
  13. < user agents implementing such a protocol can provide individuals with a
  14. < consistent view of the mail store, ...
  15. ---
  16. > manipulating message data (email or bulletin board) on a remote message
  17. > store (repository).  Mail user agents implementing such a protocol can
  18. > provide individuals with a consistent view of the message store, ...
  19.  
  20. Re: disconnected operation:
  21. < group needs to complete this effort.)
  22. ---
  23. > group will develop extensions to imap2 which provide a similar capability. 
  24.  
  25. Re: Comparison with NFS:
  26. < provide more efficient searching and message parsing.
  27. ---
  28. > provide more efficient caching, searching and message parsing.  
  29.  
  30. Re: security:
  31. < authentication mechanisms when establishing a session, and interactions
  32. < with Privacy Enhanced Mail. 
  33. ---
  34. > authentication mechanisms when establishing a session, and possible
  35. > interactions with Privacy Enhanced Mail. 
  36.  
  37. ===========================================================================
  38.  
  39. 93.4.3
  40. teg
  41.  
  42. Interactive Mail Access Protocol Working Group (imap)
  43.  
  44. Chair:
  45.  
  46.      Terry Gray             gray@cac.washington.edu
  47.  
  48. Mailing Lists:
  49.  
  50.      General Discussion:    ietf-imap@cac.washington.edu
  51.      To Subscribe:          ietf-imap-request@cac.washington.edu
  52.      Mail archive:          ftp.cac.washington.edu /imap/imap_archive
  53.  
  54. Description of Working Group:
  55.  
  56. The Internet Interactive Mail Access Protocol (IMAP) working group is
  57. chartered to refine and extend the current IMAP2 protocol as a candidate
  58. standard for a client-server Internet email protocol to manipulate remote
  59. mailboxes as if they were local.  An explicit objective is to retain
  60. compatibility with the growing installed base of IMAP2-compliant software. 
  61. It is expected that the resulting specification will replace both RFC-1176
  62. and the more recent (as yet unplublished) IMAP2bis extensions. 
  63.  
  64. A mail access protocol provides a uniform, OS-independent way of
  65. manipulating message data (email or bulletin board) on a remote message
  66. store (repository).  Mail user agents implementing such a protocol can
  67. provide individuals with a consistent view of the message store,
  68. regardless of what type of computer they are using, and regardless of
  69. where they are connected in the network.  Multiple concurrent sessions
  70. accessing a single remote mailbox, and single sessions accessing multiple
  71. remote mailboxes are both possible with this approach. 
  72.  
  73. There are no Internet standards in this area, and one is needed to define
  74. a consistent approach to the problem in the context of other Internet mail
  75. protocols including RFC-822, SMTP, and MIME.  IMAP appears to be the only
  76. existing *open* protocol that achieves the above goals. Hence, the choice
  77. is either to invent a new protocol from scratch, or to refine IMAP2. 
  78. IMAP2 is in production use at a number of large sites, and several
  79. commercial products based on it are now available. Operational experience
  80. has been very positive, and the installed base is growing.  In the absence
  81. of any serious problems with the current specifications (IMAP2 plus
  82. IMAP2bis extensions), it makes little sense to start over, nor to abandon
  83. compatibility with the installed base. 
  84.  
  85. Comparison to POP.  There is a Draft Standard describing the latest
  86. version of the Post Office protocol (POP3, RFC-1225).  POP is a
  87. store-and-forward transport protocol that allows an MUA to retrieve
  88. pending mail from a mail drop (where it is then usually deleted
  89. automatically).  IMAP, in contrast, is focused on remote mailbox
  90. manipulation rather than mail transport.  Although IMAP is a functional
  91. superset of POP and can operate in the same mode, the two have different
  92. purposes and should not be viewed as competing. 
  93.  
  94. Comparison to PCMAIL.  PCMAIL, defined in RFC-1056, uses the Distributed
  95. Mail System Protocol (DMSP).  It has been relegated to Informational
  96. status by the IAB.  A strength of DMSP is support for "disconnected
  97. operation" wherein a local message cache can be created for off-line
  98. processing, and later resynchronized with the main mail server. 
  99. Preliminary discussions have taken place with members of the DMSP
  100. community on how to fold similar capabilities into IMAP2.  The working
  101. group will develop extensions to imap2 which provide a similar capability. 
  102.  
  103. Commercial alternatives. Many of the vendor-specific remote mail access
  104. approaches are based on proprietary remote file system protocols that
  105. neither scale well nor support diverse types of client operating systems. 
  106. Others are unsuitable candidates for Internet standardization due to
  107. licensing  restrictions.
  108.  
  109. Comparison with NFS.  Achieving many of the stated goals is possible using
  110. a generic remote file access protocol such as NFS, rather than an
  111. application-specific email protocol.  However, there are also some
  112. significant drawbacks, including: file locking on the mail server in the
  113. face of concurrent local and (possibly multiple) remote updates;  network
  114. performance; and difficulty in implementing on small client machines. 
  115. Moreover, using an application-specific protocol allows the server to
  116. provide more efficient caching, searching and message parsing.  The latter
  117. is particularly important in the context of MIME, so that the client can
  118. request message structure information from the server, and thereafter
  119. retrieve only the body parts it needs. 
  120.  
  121. Security.  Security-related tasks include how to incorporate secure
  122. authentication mechanisms when establishing a session, and possible
  123. interactions with Privacy Enhanced Mail. 
  124.  
  125. This working group's IMAP standardization activity complements (and does not
  126. compete with) parallel efforts to define the "IMSP" mail support protocol
  127. which will be layered on top of the resulting IMAP protocol.  The mail
  128. support protocol work addresses issues of managing large email sites, such
  129. as determining on which mail server a particular user's incoming mail
  130. resides.  
  131.  
  132.  
  133. Goals and Milestones:
  134.  
  135. It is expected that most of the work of this group will be conducted via
  136. email. Opportunities to meet face-to-face at IETF meetings will be used
  137. initially to review the charter and context for the work, as well as
  138. presentations to help members get up to speed on IMAP.  A goal is to have
  139. the IMAP2bis draft updated and submitted as an Internet draft in the July
  140. timeframe.  The November IETF WG meeting would then focus on detailed
  141. review of the draft standard. 
  142.  
  143. Mar 93 IETF   A BOF to review the working group charter, and discuss
  144.               its relationship to the broader remote mail issues
  145.               considered in previous IETF email BOFs.  
  146.  
  147. Jul 93 IETF   Foreign travel restrictions may preclude several of 
  148.               the key players from attending the Amsterdam IETF, however,
  149.               it may be possible to schedule a WG meeting for 
  150.               presentations and to solicit input from those who are 
  151.               normally unable to attend US IETF meetings.
  152.  
  153. Nov 93 IETF   Based on continuing email refinement of the text, use 
  154.               this meeting for a detailed review of Internet draft text.
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.